perm filename PLAN.RND[RDG,DBL] blob
sn#583303 filedate 1981-05-06 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00007 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 ∂23 Mar 1981 1512-PST ROLANDA Protocol fle
C00042 00003 ∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
C00047 00004 ∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
C00049 00005 ∂16 Apr 1981 1004-PST RICK Planners' homework 16-apr-81
C00068 00006 ∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
C00081 00007 ∂6 May 1981 1552-PDT RICK bill's homework forwarded fyi
C00103 ENDMK
C⊗;
∂23 Mar 1981 1512-PST ROLANDA Protocol fle
To: Greiner
cc: Rick
Russ,
Rick asked me to send this file to you:
1
2 mon feb 16 14:22:39 pst 1981
3
4 take either saturday or sunday.
5 the route:
6 pch to topanga cyn
7 topanga to mulholland
8 mulholland to lake vista drive
9 as soon as you predict you'll get too tired to return home,
10 return, or continue to:
11
12
13 lake vista drive down to the lake
14 return:
15 lake vista drive to mulholland
16 mulholland to topanga
17 lunch: eat at one of the places around the lake, lean up against bank
18 if you return prior to reaching lake, eat lunch at tapia park down las
19 virgenes 1/4 mile
20 north on topanga to dumetz
21 country club on dumetz which is novel to him
22 east on dumetz to serrana
23 north on serrana to ventura blvd.
24 east on ventura blvd to sepulveda blvd
25 back home
26 rose & walgrove (.5 mi east of lincoln) in venice
27 right near the sm airport
28 he says it's too long! needs shortening
29
30
31 plan escape routes
32 plan phone calls
33
34
35 ----------------------------------------------------------------
36 2/18 rationale
37
38 why the mon feb 16 plan was too long: based on comparison with
39 a ride that's closely related to this plan and which he's done before,
40 i.e. if you get rid of the side trip on mulholland and replace
41 topanga by old topanga. however, this trip might be too hard in current
42 physical condition of norm.
43 from 1, this suggests getting rid of
44 going up, old topanga is more difficult but infinitely preferable:
45 less traffic,more to look at.
46 amend the plan to go up old topanga, because of 3 and we know he
47 nice things to look at.
48 look for ways to amend the mon 2/16 plan to shorten it.
49 like the basic plan: pch through the mountains, down to valley,
50 and back via sepulveda. so going to change details within this overal
51 form.
52 some changes we can make:
53 a. shorten the part of the trip west of topanga to the lake,
54 by getting rid of that part of the trip.
55 b. would this be too long? no, he can't say that, but does
56 say it might be.
57 c. thus, let's cut out malibu lake and tapia park.
58 d. what things were these things trying to achieve?
59
60 at this point let's search the rationale for lake and tapia.
61 lunch place: tapia and malibu lake
62 urinating facilities: tapia
63 review the plan rationale for the part of plan
64 from pch to sepulveda for a lunch place.
65
66 for each piece of plan, check the rationale for lunch concepts.
67 lunch stop needs something nice to look at
68 lunch needs a natural or artificial back rest for sitting
69
70
71 regarding urinating:
72 almost anywhere on old topanga will do after you start to rise
73 add to plan to pee on old topanga after it starts to rise
74
75
76 norm is willing to take a plan that doesn't specify where to lunch.
77
78 so maybe the novel country club would be a good place to eat.
79 he's not averse to risk of this sort.,
80 but golf courses around here usually have fences around them.
81 this seems to eliminate the golf course for lunch.
82 boy scout camp on red rock road looks interesting. it's not a big
83 diversion. maybe it'll do for lunch.
84 keith's intuition is that there'll be a nice place to eat around
85 there and norm can lean up against a tree.
86 norm's never been on red rock road. it looks nice he says.
87 it is hilly.
88 patch the plan: let him go out on red rock road for upto 20 minutes
89 looking for a nice place to eat. if he can't find one, turn around and
90 stop near the country club somewhere for eating.
91 barbara recommends red rock
92 ever been on calabassas peak motorway? norm says motorways are unpaved.
93 for a few months, he's been unwilling to take unpaved roads.
94 is red rock paved? it has the same symbology on the 1971 ed of
95 thomas bros la street map as calabassas peak motorway.
96 if it's paved, it's a good idea. from the map norm believes it is
97 paved, but if it were paved, he'd know about it, and since he doesn't
98 know about it, he doubts it is paved. overall, he assumes it is partly
99 paved.
100
101 he'd be willing to go on an unpaved street for a short distance,m
102 but not down hill.
103 but since it's hilly, it'd have to be downhill at least one way.
104 how about walking to lunch? he's not averse to chaining the bike
105 to a tree. he is averse to walking more than 1/8 mile.
106 1/8 mi doesn't seem to be far enough to reach lunch on red rock road.
107
108 keith complained about the lack of relevant infor on the map for
109 the planning task.
110
111 lunch at dumetz: would it be too late? depends on the time the
112 plan starts.
113
114 9am would be a reasonable time to start.
115
116 if he started at 9, he could eat lunch at dumetz. it wouldn't
117 be too late.
118
119 at the intersection of old topanga & mulholland hiway, there's
120 a high school. they generally have fields, etc., and may make a
121 nice place to eat.
122
123 keith recommended eating at that high school (see 28)
124
125 barbara thought it wouldn't satisfy the seating or view requirements.
126
127 norm hasn't been to calabassas high school.
128
129 quite often high schools on saturdays are nice places to eat, e.g.
130 soccer games, etc.
131 on sundays, norm thinks they tend to be dull.
132 barbara says both saturday and sunday at paul revere junior high
133 things happen.
134
135 so they recommend the high school for lunch, and that means
136 the plan is restricted to saturday.
137
138 patch the plan to restrict it to saturday and lunch at the high school.
139
140 possible options fromthis point, after lunch:
141 can continue on old topanga from high school until it hits mulholland
142 and then go right and take it to topanga, or can
143 go back to mulholland hiway to mulholland drive and take that to topanga.
144 these roads define a triangle of about 1.25 miles on a side, and the
145 high school is in the center of that triangle.
146
147 work on getting him back:
148
149
150 sfv map shows greater detail on the triangle in 37.
151 the high school fronts on mulholland hiway, rather than old topanga road.
152 thus, of the two alternatives in 37, suggest that norm turn on mulholland
153 hiway rather than continuing on old topanga road.
154 at the intersection of hiway and old topanga road, norm should use his
155 judgment about the best way to get to the high school.
156
157 ventura blvd between serrana ave and sepulveda is not a pleasant ride.
158 what about streets that are deeper (more north) in the valley for
159 more pleasant ride.
160 what about victory, which is 2 mi further north. less cars, good.
161 smaller shoulder than ventura.
162
163 oxnard is nicer. good things to look at and nicer than
164 ventura or victory, as in 40.
165
166 patch to plan: from serrana, continue across ventura by joggin
167 to right onto de soto, under the ventura fwy. take de soto to oxnard st.
168 right on oxnard. oxnard to tampa ave, left on tampa, right on topham st.
169 topham to white oak. topham changes names back to oxnard st.
170 continue on oxnard st to louise ave. right on louise, lousie to
171 burbank blvd.
172
173 how is burbank blvd, where it goes through the sepulveda flood
174 control basin? norm doesn't know.
175
176 44contd. turn left on burbank blvd to sepulveda blvd. cross under
177 405 (or under). right on sepulveda, go south.
178
179
180 presumably sepulveda blvd is the only way back at that point other
181 than the freeway.
182
183 there are many ways from valley up to the top of the hill
184 (the santa monica mtn).
185
186 havenhurst/calneva, a couple of miles west of sepulveda,
187 is an interesting way from the valley up the hill.
188
189 patch the plan: louise to burbank to sepulveda gets changed
190 to... right onto havenhurst from burbank. havenhurst across ventura
191 blvd, uphill, until calneva. left on calneva. calneva to mulholland
192 drive. left on mulholland to sepulveda, then south on sepulveda.
193
194 can't get directly from mulholland to sepulveda; they don't
195 intersect.
196
197 oxnard is only .5 mi north of ventura, so the oxnard detour
198 adds only 1 mile. it's completely flat, and will probably be less
199 wear and tear than riding on ventura bl.
200
201 start working on best way back from sunset & sepulveda to home.
202 bundy and centinela are bad: narrow, no shoulder, lots of traffic.
203
204 suggest: right on sunset from sepulveda
205
206 sepulveda south of sunset has no traffic but no view either.
207
208 ohio has a bike path.
209
210 patch: sepulveda, right on ohio, left on barrington.
211 barrington to gateway, right on gateway to
212
213 must get around sm airport, two possible ways.
214 bundy or ocean park or pearl st are alternatives.
215
216 redo 56
217 patch: sepulveda, right on ohio, left on barrington.
218 barrington to gateway, right on gateway to
219 ocean park, ocean park to 21st, lefton 21st,
220 continue to dewey st where he makes a left.
221 norm considers this home.
222
223 big problem with the plan is calneva, it's too steep,
224 given the amount of other things going on,.
225
226 to avoid calneva, you don't want to go on the south side of
227 ventura.
228
229 norm denies 58,but keith says it would take lots of street changes
230 to do, and norm previously said he didn't want to have to handle complicated
231 plans. that's why 58 is the way it is.
232
233 patch: south on havenhurst, left onto ventura blvd, go approx 1 mi
234 to haskell avenue, right on haskell and it will eventually turn into valley
235 vista, and thence to sepulveda.
236
237 going south on sepulveda from that general vicinity, it's
238 better to get off burbank before crossing havenhurst otherwise you'll
239 have to go through lots of freeway underpasses and add distance.
240 inferring that there'll be traffic near freeways, freeway exits, and
241 oxnard is near the freeway around there.
242
243 in generally, there's a tension between simplifying the plan to
244 lots of turns etc vs. minimizing traffic.
245
246 biggest current problem is going up topanga from ocean on saturday
247 morning when there's lots of traffic coming to the beach.
248
249 in norm's present condition, there's no way other than topanga
250 up to that part of the mountains without going out to malibu, which
251 is too far west.
252
253 basic conflict: up topanga on saturday is unacceptable; lunch at
254 high school on sunday, would be acceptable assuming he can get in.
255
256 patch: switch the plan to sunday.
257
258 the current big problems:
259 need to provide for rand stop
260 provide for equipment malfunction
261 provide for water along the way
262 not enough plans for urinating along the way
263
264
265
266
267
268
269 patch in plan: topanga to old topanga, old topanga to mulholland
270
271
272
273
274
275
276
277 hiway, east back to topanga canyon, north to dumetz, then as per 2/16
278 plan.
279 lake callabasas doesn't exist as far as norm knows
280 considering sending him up old topanga to lake callabasas to shorten the
281 trip
282
283 ---------------------------------------------------------------------
284 2/16 rationale
285 there are urinating facilities at tapia park
286 limit a ride to 6 hrs total elapsed time
287 the length of daylight constrains the trip, wants to go in daylight
288 the ideal temperature is 60 degrees
289 temperatures below 90 is okay
290 even 40- degrees at low end is okay
291 speed is 10-15 mph on flat surface, including traffic delays
292 we derived his speed up mandeville cyn road is 7.5 mph
293 he's not in the best of shape right now
294 all these things led us to a round trip of around 45 mi
295 tuna canyon has been closed for two years, and it's too steep
296 piuma climbs from las virgenes to rambla pacifica
297 rambla pacific is very steep for descent, too steep if the rest of ride
298 was hard
299 lunch stop needs something nice to look at
300 lunch needs a natural or artificial back rest for sitting
301 urinating needs a restroom or not too public place
302 nice beach day, pch from malibu to santa monica is unpleasant due to
303 traffic from surfboarders, in afternoon
304 on non-sundays, topanga has excessive traffic
305 theorem: getting back from santa monica mountains on the weekend requires
306 an inland route to avoid these conditions
307 doesn't like descending topanga canyon in traffic because it's grueling
308 steep descents require resting places periodically (not topanga, but
309 rambla pacifica)
310 tuna canyon was steepest grade in west la county
311 good view at mulholland and malibu canyon (purple cows)
312 lunch place: tapia park below mulholland
313 lunch place: malibu lake
314 dirt roads are out, unless very short
315 doesn't like riding in flat places, such as san pedro
316 coast bicycle path has too many pedestrians et al in the afternoon
317 he likes hills
318 6am in the morning is too cold in this season
319 map distance measurer is 4.4 mi per inch on the la & vicinty map according
320 to kw's calculation
321 coast hiway to malibu from sm is perfectly flat
322 in his current condition, he doesn't think he can do the whole trip
323 which was rand to topanga, to mulholland, to malibu cyn, and
324 back through valley.
325 but the trip was generally nice anyhow
326
327
328 -----------------------------------------------
329 2/20
330
331 coast hgh to top to old top to calabassas hs to mulholland to
332 top to dumetz to serrana jog to right to desoto
333 north to oxnard east to topham=oxnard right on whiteoak
334 left on burbank to havenhurst left on ventura right on
335 haskell=valley vista right on sepulveda...
336 sepulveda, right on ohio, left on barrington.
337 barrington to gateway, right on gateway to
338 ocean park, ocean park to 21st, lefton 21st,
339 continue to dewey st where he makes a left.
340 norm considers this home.
341
342 the current big problems:
343 need to provide for rand stop
344 provide for equipment malfunction
345 provide for water along the way
346 not enough plans for urinating along the way
347
348
349 norm: if i go north, must stop at rand either coming or going
350
351 norm: early in am must urinate more often; cannot wait until old topanga
352
353 norm: where to urinate aftyer old topanga--need one more
354
355 norem: need to stop to wash once, depending on how hot
356
357 norm: carried water too prescious to wait on hot days
358
359 norm: might not be hot in near future
360
361 rick: been hot last few days
362
363 norm: wash stop also necessary to refresh water bottle
364
365 norm: one water bottle on cool day, more on hot day
366
367 if can fix bike myself (e.g., flat tire) need time to
368 fix and get home before dark
369
370 if cannot fix myself, may be immobile
371 for going up
372 for going up or down
373
374 try to plan route with only one steep uphill
375 can push bike up one mild uphill
376 walking is hard
377 route too far to walk all the way home
378 bicycle could be fixed at bike shop if near enough
379 can call for help
380 can't call from san fernando valley
381 wife can't drive that far--too far
382 but she could come if absolutely necessary--very unlikely
383 must be coordination with wife for emergency calls
384 daughter drives, but have never used her
385 3-4 bicycle shops on ventura between top and sepulveda
386 some shops on sunday
387 phone book at every phone booth in valley
388 many phone booths on ventura
389 can coast downhill from mulholland & top to top & ventura
390 if chain breaks, can get to coast highway
391 most frequent malfunction- flat tire, fix myself
392 carry spare tire, 2 spare tubes, pump
393 takes half hour in dirty clothes to change tire, longer in clean cloth
394 norm knows route time from experience
395 this route takes 3-4 hours, not including stops
396 prefers 2 hours rest
397 worst thing would be getting hit by car
398 precautions too detailed to worry about
399 most likely problem that could add delay: flat tire
400 next: too tired to proceed safely
401 or non-repairable equipment malfunction (e.g., broken chain)
402 chain has broken 4-5 times
403 doesn't carry universal link because doesn't know how to
404 take apart chain right, tried once and broke it
405 gear shift cables can break
406 doesn't carry spare cables because can't/won't fix self
407 normally just adjust mechanism so remains in low gear+>
408 get home, but slowly
409 carry screw driver, wrench, tire iron, etc.
410 break cable broke once
411 couldn't gop down topanga or ride bicycle without break cable
412 above suggests need bike shop on valley side of hill
413 under plan, would never be more than mile away
414 on sunday, 4 miles between top & sep => could be further
415 norm suspects 3-4 miles
416 he would walk
417 15 minutes to walk mile => 1 hour to walk 4
418 only thing worse is handbreak breaking
419 norm: highly unlikely and would call for help
420 takes bag full of dimes
421 rick wants norm to take nickels and quarters in case dime slot jammed
422 longest current stretch with no phone is not too long
423 longest (time) stretch with no potty is from house to beginning
424 of unsettles old top (1.5-2 hours) at difficult time of day
425 therefore, should go to rand on way out
426 can pee at rand
427 can pee at public potty on coast highway
428 norm always carries catheter
429 needs to pee after lunch--at school
430 school is not far from ventura
431 needs to refill water bottle in case hot day
432 can stop at gas stations to fill bottle if open
433 they close on sundays
434 there is a restaurant intersection vent and topo open on sundays
435 too far? no it's all downhill
436 must lock bioke to go in restaurant
437 patch plan: pee at vent/top restaurant, get water, fill bottle, clean face
438 if hs yard open, might have fountain for splashing, etc.
439 hs yard might be closed on sundays
440 it's a county school
441 might have field open
442 norm won't climb fence
443 needs second source of water in case hot day
444 never has run out of water on way up old top
445 always fills water bottle before goes up
446 can fill it at beach potty
447 patch plan: fill water bottle at beach potty
448 needs to pee after top/vetn at least once near sepulveda
449 many gas stations near there
450 prefers not to pee in gas stations
451 not many places on sepulveda where can pee
452 many public parks where can pee
453 parks better than gas stations for peeing
454 gas stations are incredibly dirty
455 prefer not to touch door handle in gas station
456 plan patch: when on burbank, stop at sepulveda recreation area too pee
457 norm wants to take a side trip to the model airport
458 he prefers watching female roller skaters over male model fliers if hot day
459 need potty this side of mountain...just in case
460 va cemetery has nice potty--immaculately clean
461 time estimate
462 3-4 hr for bicycling
463 2 hr side trips and rest, including peeing
464 1 hr to walk to repair shop
465 1 hr for repair
466 2 hr for repair shop enough for self repair
467 max elapsed time = 8 hours +← stop at rand = 1 hr or less
468 max time = 9hr
469 est is too long
470 once reach bottom of hill on sepulveda, if it's too dark can call wife
471 earliest come to rand=8
472 best time to leave rand & start current trip depends on temp
473 plan patch: arrive at rand 7:30
474 because it's cold in morning, don't want to start too early
475 earlier better, but not if too cold
476 want to leave time for other things
477 depart rand by 8:30
478 1 hour more than enough & want to get on road as soon as poss.
479 reach hs no later than noon
480 whole trip only takes 3-4 hours
481 if doesn't reach halfway point by 3 hours, something wrong
482 reach vent-sepulveda by 3
483 3 hours for third of trip + lunch is plenty
484 if don't get there in time, stuck
485 correction: vent/sep by 4
486 because if all goes well takes 2 hours to get home from there
487 dark by 6:15
488 if doesn't get there by 4
489 can't call naomi or walk
490 doesn't know if daughter will be home then
491 could but rarely takes taxi
492 rick won't be there 2/22
493 nothing like this has happened before
494 norm would call naomi & ask her to find someone else
495 otherwise taxi to sep&sunset
496 arrive home by 6
497 if fall behind schedule on this side of mountain, return home
498 if fall behind on that side,
499 do not take trip if rains
500 if rick picks up norm, he should pick up faucet
501 norm will take care of clothes and newspapers
502 clothes must suit weather
503 if cold before 9, take newspapers because disposable
504 norm doesn't know what naomi is doing any sunday
505 patch plan:
506 coordinate to reach naomi at 3 or 4
507 norm believes can do
508 be at phone at 3 or 4
509 should know by 3 if falling behind 4 deadline
510 assume, with no malfunction, will reach sep & vent by 3
511 assume, with malfunction, will reach sep & vent by 4
512 if above fails, take taxi to whatever point necessary to get home
513 take $20
514 will cover taxi fare
515 but may need more if repairs
516 usually carries only dimes & credit cards
517 take $50
518 he doesn't want to
519 take $20
520 what if it rains during trip?
521 doesn't carry rain suit
522 doesn't have suitable one
523 usually, if it rains, he takes easiest route home
524 can't really ride in rain suit
525 gortex would work
526 doesn't want to spend money on gortex
527 problem trivial compared to hand break not working when wheels wet
528 riding in rain in certain conditions unacceptable for long period
529 rain is problem only in afternoon, after 4
530 unlikely to forecast rain
531 rick thinks forecast overestimate rain chances
532 norm would go if chance of hard continuing rain at top of topanga = 5-10%
533 this is worst possible rain
534 norm won't go with any chance of rain
535 rain info from weather service -- not reachable when rain predicted
536 flight service provides useful info only 10% of time
537 patch plan: go only if 0% perceived prob rain
538 norm doesn't want to get wet
539 norm doesn't want to ride down top with wet rims
540 patch plan: norm will plan tactics
541 need route sheet
542 patch plan: night ahead, norm should prepare route sheet
**************
Rolanda
-------
---------------
-------
∂14 Apr 1981 1612-PST RICK at RAND-AI Re: Defn of Task
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1238-PST
Russ:
We may eventually constrain, a little but not greatly, the form of the
users' input away from free-form english. We are even considering parsing it
using a good general parser. However, you're on the right track to
think about scanning the input to build conceptual (what you called "keyword")
tags to hang on the sentences. Your task is to enable conceptual labeling,
with arbitarily interesting sources of matching between input and
concepts. To do this, you need to develop a language for describing concepts
and the ways they are realized in inputs. This is different from parsing, in
general, because each distinct user group will speak a different "language"
and will need to emphasize different concepts.
For example, you might want to develop some concepts related to
preferences. Norm has preferences for certain kinds of things and against
others. The relationship between a thing and norm's preference for it
often is the basis for it being included or excluded in the plan. We
need a way to succinctly express such a relationship and have it recognized
in the input so it can be stored and matched (with other inputs, called queries,
which also exhibit it).
Another example, we had something in the concept taxonomy that
barbara prepared having to do with "interesting." However, when we had
a replanning session focused on "make a new route for norm which is changed
as little as necessary but which is less boring than simply repeating the
same route would be," the guy wanted to find anything about "boring" but
couldn't. Find x such that x bores norm is the query. How should we find it?
How can we insure that if it's there, we will actually find it. How can we
express heuristically defined alternative queries that we think will satisfy
the retrieval goal? How should we retain these definitions? Should all
of these automatically be processed for each input and stored with it for
subsequent matching?
e.g., Norm thinks x is dull => x bores norm
e.g., Norm thinks P => interesting but }P(x) , thus is x un-interesting?
e.g., Interesting (x) => }boring (x)
e.g., Tacit: more familiar => more boring & more recent => more
familiar
I hope this gives you enough grist to move on.
My image of what you're producing is a front-end to RLL to let me build
my own conceptual definitions easily; a matching method that finds instances
of concepts in inputs; a matching method to find stored things that
correspond to coneptual descriptions; and a method to extend or rectify
conceptual defintions in light of errorful performance or new desires.
Push on!
Rick
-------
∂14 Apr 1981 1617-PST RICK at RAND-AI Re: The real message is
To: CSD.GREINER at SU-SCORE
cc: greiner at RAND-AI, RICK at RAND-AI
In-Reply-To: Your message of 14-Apr-81 1318-PST
I'll send you a more detailed problem statement for the project before
leaving for this weekend. Then, I'd like to have you down at rand in
the first week of may to attend a planners' pencil planning meeting.
Either weds or frid would be best. I expect the stuff you are doing
will get along fine for three weeks without direct interactions.
Let me know if you feel otherwise.
Cheers,
Rick
-------
∂16 Apr 1981 1004-PST RICK Planners' homework 16-apr-81
To: bill, greiner, wescourt, barbara at RAND-UNIX, norm at RAND-UNIX
cc: rick
Here's my entry:
0<RICK.PLANNER>PENCIL.HOMEWORK.1 10-Apr-81 10:23:16, Edit by RICK
The question: Is the pencil better/worse/potentially better than
using the protocol?
Answers:
BETTER:
> because it identifies early what the planners wound up believing,
rather than their initial or intermediate ideas
> because it helps answer questions about hypotheticals the replanner
comes up with
> because it identifies the many ways one decision supports others
> because it tells the replanner why some currently considered
alternative was previously rejected (and usually is still bad)
> because it saves time in rejustifying unchanged parts of the plan
WORSE:
> it fails to establish a coherent picture around each idea, since
the units are atomic, the pointers bring in clusters, but most
trains of thought are linear when being developed or absorbed
> currently, the replanner needs to absorb and organize mentally the things
kludge spits out at him before he can deal with them
> thus, although the plan rationale is structured, the structure
used doesn't help him solve his problem
> data get lost and mangled from protocol to items file
> the process is hard, unsystematic, error-prone
> the uniform & simple type of rationale structure with a list of
pros & cons can't convey which of the supports was most influential,
which least, etc., but conveys the misimpression of equal importance
POTENTIALLY BETTER:
> if it provides a linearized readable explanation of why choices were made
> i would like to see a "movie" of the evolution of the plan,
what Keith called the rationale for the rationale
> if it provides a linearized set of alternatives for each choice and
makes it easy to see the pros and cons of each
> if it organizes the plan into a hierarchy of subplans,
the rationale into a hierarchy of goal-achievement proofs,
the assumptions into a hierarchy of inherited assumptions informing each
phase of planning (hence some temporally related collection of
plan rationale parts),
the alternatives for each plan element with their corresponding effects
(goal/constraint attainment/failure)
> if articulation were systematic
> if people could find the answers to their questions
HOW TO IMPROVE THE EXPERIMENT
> make the replanner autonomous
> make the items in the rationale self-explanatory
> give the replanner software training and clear instructions
> use ourselves as subjects rather than others
> divide into two groups then transfer to the others' problems
> take a part of the planners' workbench as the task
> prescribe replanning strategies
> build abstractions into the plan & rationale
-------
Date: 16 Apr 1981 1008-PST
From: RICK
Subject: test of planner mailing list
To: wescourt, bill, greiner, randvax!norm at RAND-UNIX, randvax!barbara at RAND-UNIX
cc: rick
only tell me if you don't receive this please where you want it
-------
Date: 16 Apr 1981 1037-PST
From: Keith Wescourt <WESCOURT>
Subject: Homework
To: Planner: ;
QUESTION:
Is our current system, KLUDGE, for describing plans better
than a raw protocol?
Before considering the pros and cons of Kludge vs the protocol,
I think it is important to note several facts:
(1) The protocol we have is a very poor one relative to what a
protocol could be. Not that we did try hard, but the coverage
and detail suffer in comparison to what a trained stenographer
could have captured. Therefore, the limitations of the present
protocol may not all generalize and its strengths may have the
potential for further enhancement.
(2) However, if the protocol were more detailed, it would also be
longer and thus less manageable. This would be aggravated in the
protocol of planning sessions for a more complex problem.
Therefore, comparisons of the current protocol with Kludge depend
on the extent of this particular exercise and may not generalize
to smaller or larger scale planning.
(3) Since, the database we used in the current exercise with
Kludge was almost entirely based on the protocol, the use of
Kludge inherited some of the defects of the protocol.
PRO the PROTOCOL:
(1) The obvious: the protocol contains more information. We got
most of the facts and reasoning from the protocol into the rationale
items, but there is other transitional information-- e.g., statements
of questions raised by group members-- that provides context lacking
in the rationale database.
(2) In general, the protocol better conveys some aspects of the
structure of the rationale for plan steps. First, in the protocol you
can see whether a plan step was determined by a generate-and-test
method or by a specify-and-search method. By generate-and-test, I
mean that a tentative plan step was initially generated from a single
goal/contraint; for example, it is a route segment that connects two points
the planned course should reach. That plan step is then "tested" by
an attempt to generate rationale that supports the conclusion that it
satisfies/does-not-violate other goals/constraints. Specify-and-search
on the other hand, involves first stating a rationale involving
multiple goals/constaints and then looking for plan step consistent with
that rationale. Too much shouldn't be made of this distinction, since
the two techniques chain together; it is probably better to think of
a general split of rationalizing that takes place before or after a
tentative plan step is generated. I think the importance of knowing
this distribution for replanning is that it helps indicate the
likeliest ways to change plan steps without perturbing other parts of the
plan. For the most part, it is easier to change plan steps along
lines that have to do with the rationale following a plan step
determined by generate-and-test.
(3) Even if you don't believe the preceding claim, there is a more
general advantage of having the temporal information in the protocol.
The order of rationale development for a plan step conveys which
assertions were most critical for supporting or rejecting a conclusion.
In fact, the complexity of the trade-off between the pros and cons
for a plan step is much more obvious. Thus, in replanning, if one has
the protocol it is easier to see which goals/constraints it is most important
for modified plan steps to satisfy.
(4) The protocol better shows the evolution of the plan. You not only
know which plan steps and rationale are in and out, but when they
went in or out relative to other plan steps. Knowing this dependency
information allows one to use some simple heuristics about which
changes during replanning are least likely to interact with the
remainder of the plan.
PRO KLUDGE and its rationale database.
(1) The obvious: once you have a feeling for the Gestalt of the
problem and the concepts/vocabulary of the rationale database, it
is much easier to retrieve items about specific concepts and to
trace the full set of assumptions underlying the acceptance or exclusion
of a plan step. For simply searching, the Kludge software is much
superior to examining the protocol, even if one has the protocol
in a regular editor and can bounce around looking for strings.
In addition, the rationale file provides a much more explicit representation
of the arguments that the raw protocol. As the raw protocol progresses,
assumptions for similar types of arguments are often not repeated.
Unless one has very comprehensive mental picture of the entire
protocol, then it is easy to miss that a plan step has some rationale
that is not articulated in the protocol at the point where the
plan step is proposed. The coding of the rationale items and their
relationships made all the implicit rationale explicit for Kludge.
(2) While the protocol seems better for seeing which assumptions/assertions
are most vital to deriving a specific plan step, Kludge is much
better for determining which assumptions/assertions are vital because they
are involved in the derivation of several seemingly disjoint plan steps.
Thus, for example, during replanning, if one is contemplating a change
to a plan step that would cause a goal or constraint to no longer
be satisfied, then one can easily check (via ramify) whether there are
remaining plan steps that still satisfy it and thereby make the
proposed change acceptable (e.g., if you want to change a route segment
that has a potential water stop, you can check to see if the
adjacent route segments have alternative water stops in their supporting
rationale). To summarize, Kludge is better than the protocol for
determining those relationships between rationale and plan steps and
between plan steps that are not tied to the temporal structure of
the planning process (and protocol).
RECOMMENDATIONS
(1) It might be worth considering whether one wants to view protocols
and Kludge-like software are mutually exclusive. They seem to have
complementary features. Besides, for the foreseeable future I see
no way of going from planning to encoded rationale without a protocol,
unless we determine that planning must be done in a structured environment
which includes rationale elicitation. There are problems with keeping
protocols around, however. They are long, especially if they are
properly recorded and if they are for problems of greater scope than
the one we considered in our exercise. Reading the protocol may thus
be costly and less effective for the replanners.
(2) I see a couple of alternatives for improving Kludge to provide
the information one can get from the protocol. As long as a protocol
is around, I see the simplest alternative to be adding pointers from
encoded rationale items back the protocol and providing a way
within Kludge to retrieve the actual protocol text from which encoded
plan steps and supporting arguments were drawn. In a sense we have this
in a rudimentary form now, because most of the item names reference
lines in the protocol; one can therefore go from Kludge output back
to the protocol to selectively review the full context of rationale.
However, this is clumsy. I can easily see protocol pointers in each
rationale item that allow the user to jump into an editor/scroller
at the proper place in the protocol to more fully explore a bit
of "raw" rationale. A second, harder alternative would be to directly
encode the temporal structure of rationale into the encoded rationale
database. This might include adding temporal pointers between the
items used to rationalize a plan step or another rationale item (for
multi-level rationales). It might include annotating each item with
a "priority" tag indicating it's degree of importance in a particular
argument. Representing this additional knowledge may not be very easy,
particularly for items that appear in multiple arguments. In addition,
representing changes in the importance of an item within a rationale
over time would be hard I think. In general, I guess what I see as
necessary is a full history mechanism for representing not just the
final role of each item in the encoded rationale, but a representation
of its role at each point during the evolution of the plan. I claim
that such a history may not be particularly important for verifying
whether the paln is still valid before executing it, but is very
important for replanning to keep the replanners from duplicating
errors the original planners already recognized and eliminated.
-------
∂17 Apr 1981 1228-PST RICK Planners' Workbench project-plan for remainder of FY81
To: bill, randvax!norm at RAND-UNIX, greiner, randvax!barbara at RAND-UNIX
cc: rick, wescourt
Folks:
Here is my cut at the project-plan. When time permits,
I will encode it into a plan rationale.
In the meantime, read it, digest it, ponder it. Guide your
behavior so that it's in accordance with the plan thrust or initiate
plan changes.
We will meet 1:30 Friday May 8 to discuss the eventual form of
this plan.
I hope it suits you. It attempts to reflect your interests
and strengths, but it's just an initial guess at those.
Rick
----------------------
0<RICK.PLANNER>WORKBENCH.TODO.2 17-Apr-81 12:18:44, Edit by RICK
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: elicitation, dimensions,constraints, strategies/tactics of the plan
=> these must fit the structure of a good "rationale"
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20
∂6 May 1981 1552-PDT RICK bill's homework forwarded fyi
To: barbara at RAND-UNIX, greiner
cc: rick
∂6 May 1981 1538-PDT BILL workbench.todo homework
To: rick
cc: norm at RAND-AI, barbara, wescourt
Additions to my copy of WORKBENCH.TODO are indicated below by ":>"
in lieu of ">". The suggestion that we (1) anchor what we do at one
end with protocols and rationale and at the other end by standard
planning tools, such as Gantt charts, and (2) use a Rand management
plan other than the workbench plan for the demo.
WORKBENCH.TODO
Goals: (Level-1)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Everybody doing a piece of the coding and using the system
> A usable tool
> Complete our Kludge experiments by June 1
> Complete our Successor design by Aug 1
(Level-2)
> Demonstrate a workbench by Oct 1 or soon thereafter
> Good conceptual retrieval
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> Some graphic display
> Some graphic editing
> Reasonably complex problem
> Answer whether plan rationale violated by changed assumption
> Answer "WHY?" any action is being done
> Answer "WHY NOT?" any action is not being done
> Answer "WHY SHOULD NOT?" an action be done
> Answer "WHY OUGHT?" an action be done
> Answer "What must be done to do X"
> Answer what conditions some proposed action needs to satisfy
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Attribute, date, and mark items in/out
> Everybody doing a piece of the coding and using the system
> Each person has an area of responsibility
> Each specifies what he/she wants to produce
> Collaboration to integrate designs
> A usable tool
> Viable, friendly, moderate speed and size
> A good self-contained demo & tutorial
:> Usable by some specific group of planners
> Complete our Kludge experiments by June 1
> Rerun the experiment
> Run the experiment on ourselves
> Complete our Successor (Workbench-0) design by Aug 1
> Define a coherent but subset of capabilities do-able in 2 months
> Define a useful example
(Level-3 through Level-5)
> Good conceptual retrieval
> Preprocess items to attach conceptual descriptions to them
> This is the parsing dual of macro expansion now used
> For each match, recode as parse tree
> Match conceptual questions only with conceptual descriptions
> Match the parse tree for conceptual questions with
precomputed conceptual match parse trees
> E.g., WHAT DOES norm like? --> Norm likes ?X -->
(norm|norman|norm shapiro)
NOUN-VERB-Connectors
(likes|wants|prefers|desires|seeks)
VERB-OBJECT-connectors
(to VERB-PHRASE(?X) | NOUN-PHRASE(?X))
> Highlight match
> A body of standard questions (parameterized question types)
> Allow a flexible language for describing patterns of both
conceptual and string matching
> These may be conjoined, with conceptual matching first,
then string matching on appropriately highlighted parts
Parse sentences
> Syntactic matches
> Easy conceptual extension
> Good plan rationale entry, especially proof construction
> How about a structure like the one I'm using?
> Indentation means subgoal/action for outer block
> Need hierarchies of assumptions to avoid repetition
> Need implicit satisfaction of constraints by all actions
> Most choices are better than alternatives because the alts don't
satisfy one of the implicit constraints--which one?
> Some graphic display
> If we use this type of structure, indented material doesn't
show up without zooming in for detail (corresponds to generations)
> Varying attributes/dates/designations of items => varying symbols
> Text abstraction (to limit area reqts)
> Some graphic editing
> Adding or deleting items in 2-d, changing their text
> Reasonably complex problem
> Plan for the workbench itself
> good for everyone!
> Emergency replanning task
> A military one
> Something with the B1 bombers vs. cruise missile vs. 747s etc.
> Use the bike trip as a transfer test source
> Answer whether plan rationale violated by changed assumption
> Propagate change through the net, semi-automatically
> Some machine inference
> Time scheduling operations and constraints
> Parameterize time and ramify time
> Answer "WHY?" any action is being done
> It's necessary for one of the goals, constraints, or precondition
for some action (e.g. like the next one in sequence)
> It helps achieve one of these, better than the alternatives
> Answer "WHY NOT?" any action is not being done
> It violates or hurts one of the goals, constraints, or preconditions
for some action
> It's worse than an alternative
> Answer "WHY SHOULD NOT?" an action be done
> Like WHY NOT? for hypothetical action
> Answer "WHY OUGHT?" an action be done
> Like WHY for hypothetical action
> Answer "What must be done to do X"
> Preconditions & constraints for that X satisfies
> Special case, what must be done before/after doing x
> Special case, what requirements arise if we want to do x
> Answer what conditions some proposed action needs to satisfy
> Same as "What must be done to do X" for a hypothetical X
> Identify unproved plan parts
> Tell how a proprosed action undoes the plan proof
> Combine WHY SHOULD NOT,ramify change & identify unproved plan parts
> Attribute, date, and mark items in/out
> What was the plan on day 1? On day 2?
> What was in on day 1 but out on day 2? WHY NOT each of these?
> Who made the plan, what's the rationale according to various people?
:> Usable by some specific group of planners
:> Group other than the core group
:> Much greater credibility among potential users/clients
:> Broaden the base of planning inputs to workbench design
:> Not much harder to do than demo based on workbench planning
:> Doesn't preclude using workbench for workbench planning
:> Management planners
:> Structure of management plans is well-known and fairly well
standardized
:> At the highest level, output should be practically identical to
planning output presently used
:> Highest level output should be in form of Gantt charts,
manpower utilization charts, and (possibly) critical path
networks
:> Identical-to-normal output makes planners comfortable,
feeling in-control, and makes any use of workbench entirely
voluntary--hence no opposition to workbench
:> Identical-to-normal output is immediately and unquestionably
useful and usable
:> Presently used planning methods have limitations workbench could
help overcome
:> Changing dates means redrawing charts; graphic capability to
do this would be welcomed
:> Shifting resources impacts several planning tools/displays;
modifying the workbench database could kill several birds with
one stone and assure consistency among plan parts/displays
:> Presently used methods entirely devoid of supporting rationale
:> Keeping plan current is often considered not worth the effort;
challenge to workbench would be to make plan maintenance
worth the effort
:> Management support is needed to fund workbench research;
management is already familiar with strengths and weaknesses of
current management planning; easiest demo for funders to relate to
:> It is essential that the program/project manager personally want
to use our highest level (identical-to-normal) output in managing
:> In-house Rand planners
:> Would facilitate close liaison between planners and workbench
researchers
:> Possibly ICJ research program planners
:> ICJ would probably benefit from improved planning
:> ICJ has to replan as result of revised funding and outcomes
of research projects
:> Rationale for ICJ research is complex, hard to untangle,
easy to lose sight of as things change
:> To the extent that ICJ is using some AI (Waterman/Peterson
work on modeling legal systems using ROSIE), there is some
sympathy with AI applications
:> Bill thinks Steve Carroll might be receptive to the idea,
possibly partially funding Bill during the summer to implement
it
:> Demonstration of workbench being a demonstration of ICJ
management planning might, in itself, be useful to ICJ, for it
to use as a demonstration, showing synergism of ICJ with Rand
:> ICJ not military--drawback from ARPA perspective
:> Possibly Strategic Assessment Center planners
:> SAC currently expects funding for June-September on-board in
June
:> SAC has already gone through several replanning phases; more
to be expected
:> There are divergent views on what SAC should be doing
:> Divergent views within Rand
:> Divergent views among clients
:> Workbench could help sort them out; help tailor briefings
to specific audiences
:> SAC has some sympathy with AI applications, using game-playing
in Red/Blue agents (Gillogly) and ROSIE heuristic modeling in
Scenario agent (Dewar/Schwabe)
:> Demonstration of workbench being also a demonstration of
SAC management planning might, in itself, be useful to SAC,
for it to use as a demonstration
:> SAC military--advantage from ARPA perspective
Initial proposed areas of principal personal responsibilities:
barbara: articulation, abstraction & rationale
=> define the structure of a "good" rationale
bill: identify planning/replanning output that
(1) could be produced by workbench
(2) would be on 8 1/2 x 11 inch paper
(3) would be nearly identical to planning output
planners would use without workbench
(by end of July)
code software to prepare the above identical-to-normal
planning/replanning output from workbench-produced files,
using software existing on VAX as much as possible
(August-September)
elicit SAC planning/replanning items and rationale from interviews
and existing memos; work with other core group members getting
rationale into proper form
(May-June)
elicit ongoing SAC planning/replanning information
(July-September; possibly SAC funded)
help identify capabilities that would be useful to management
planners in linking task plans, resource plans, and research plans
and that the workbench (demo version or subsequent version) could
provide; develop and maintain a "wish list"
(May-September)
norm: database, ramification, all interfaces, system design,
integration, configuration control,
graphics & other forms of presentation
keith: plan evolution (retro & pro-active) & question-answering
rick: conceptual encoding & retrieval
System development parts and issues
> Machines/systems and lack of high bandwidth comm
> Graphics--generate to AED which will be on pdp 20
> Plan entry and modification
>> unix, english parser, yacc, lex
> Data base
>> unix, berkeley's rdb system (isis)
> Conceptual encoding
>> lisp, ellie/yacc
> Query language
>> lisp, ellie/yacc
> Searching
>> rll, lisp, grep, isis
> Display
>> small talk, megatek, which processor?
> Intermediate files
> auto file mgt
>> tops20, unix
> helpful ways to find, label, manage working files
>> tops20, unix
> Hardcopy
> session traces
>> unix, laser
> plans
>> flowcharting software
> rationales
>> flowcharting software
> graphics
>> device?
> Multiperson sharing
>> rosie front-end & rosie-to-rosie or unix/tops20